In the prior art, there have been numerous attempts to provide computer software budget management tools. Many of those tools graphically represent budget data using bar graphs and pie charts. Neither has proven satisfactory, as explained below.
Referring to FIG. 1a, an example bar graph 101 depicting personal budget data is shown. The bar graph shows budget categories for auto expenses 102, home expenses 103, food 104, and recreation or fun 105 for a chosen period of time, such as the current month or current year. Within each budget category, the bar graph depicts total budget amount for that category versus amount spent to date. For example, for auto expenses 102, a person can view actual auto expenses 102a versus budgeted auto expenses 102b in order to visually determine whether the person is under budget or over budget in that category. For the home budget category 103, the person in question has spent more on home expenses 103a than budgeted 103b, and that overage is depicted in the bar graph. The bar graph may also show budgeted amount versus actual amount spent in numeric form such as depicted with reference numerals 102c, 103c, 104c and 105c. Note that a fine level of detail of graphic display is necessary for a bar graph depiction, something that may not be available with graphic compaction such as on a hand held computing device. Also, the bar graph shows all budget categories being the same size, although undoubtedly some are larger than others. Thus a small budget overage in a small budget category such as food may appear to be equal to a large dollar overage in another category such as home expenses, although they are not at all equal. This can tend to mislead a user who relies on visual representation of the data.
It has also been recognized in the prior art that it is desirable to be able to warn a user when a budget item is approaching the budgeted amount, and to again warn a user when a budgeted item has exceeded the budgeted amount. For example, if a user's recent coffee purchases have caused a user to approach the budgeted amount for food expenses, then a warning to that user will be helpful to remind the user to cut back on or otherwise control expenses in that category. As another example, if a user's recent automobile repair bills have caused his or her budget for automobile expenses to be exceeded, then a warning to the user is appropriate so that the user can plan to cut back on other expenses, such as entertainment or clothing, in order to stay within budget overall.
Prior art software systems attempted to provide such warnings to users by colorizing budget data. As an example, expenses in a particular budget category which were approaching the budgeted amount were highlighted in yellow, while expenses that exceeded the budgeted amount for a particular budget category were shown in red.
Bar graphs may be depicted horizontally as in FIG. 1a or vertically if desired, such as shown in FIG. 1b. That figure shows budgets in relative size to each other. However, as budgets increase in size, one category will tend to dwarf the others, making all but the largest budget categories very difficult to visually comprehend with this type of data representation.
One attempt to resolve difficulties with bar graphs is to group budgets of similar size together. This is depicted in FIG. 1c. In this example, greater than $1,000 budgets 110, such as auto 111 and home 112 are grouped together. Likewise, small budgets such as less than $30 budgets 113 such as fun 114 and internet 115 are grouped together. This is an attempt to resolve the problems inherent in bar graphs.
Regardless, bar graphs face serious drawbacks. First, if a particular budget is large compared to the others depicted on a bar graph, then the budget items which are not large must be shrunk to accommodate a large graphic for the large budget. This makes the budgets that are not large difficult to see and difficult to visually interpret, especially on a mobile electronic device. Second, bar graphs must utilize the same space to depict actual expenses versus budgeted expenses for any particular budget line item. This makes the budget line items difficult to see and understand. Third, bar graphs are not intuitive. Rather than glancing at a bar graph budget versus actual expense depiction and immediately understanding the budgetary situation, users tend to stare at the bar graphs, considering whether a particular expense might be ⅔ budget, ¾ budget, etc. Some users even find that numerical data is easier to comprehend than bar graphs.
An alternative to bar graphs which is known in the prior art is the pie chart. FIG. 2 depicts an example of pie charts 201 used to depict personal budget data. The pie charts show budget categories for home expenses 202, auto expenses 203, food 204, and miscellaneous 205 for a chosen period of time, such as the current month or current year. Within each budget category, a pie chart depicts the total budget amount for that category versus amount spent to date (shaded). Pie charts allow a person to visually determine whether the person is under budget or over budget in any particular budget category.
There are numerous problems with pie charts. First, there is a limit to the amount of information that can be depicted on a single pie chart before it becomes too crowded and complicated for easy understanding, Second, due to the size and complexity limits inherent in pie charts, in many instances all data desired cannot be represented on a single pie chart. Therefore multiple pie charts are used, making the data presentation complex when the whole purpose of using a pie chart in the first place was to simplify data presentation. A third problem with pie charts is that it can be difficult to show actual expenses versus budget amounts.
The above problems of prior art methods for graphically depicting personal budget information are compounded by two additional factors. First, a typical computer software budgeting package will include more than just budgetary graphics on a single page or screen. Therefore, the budgetary graphics must be shrunk into only a minor portion of a computer display device, consequently compounding the problems already mentioned. Second, many users would like to access their budgeting software on a mobile electronic device, such as a so-called smart phone. Mobile electronic devices tend to have compact display devices or screens, requiring further compression of budgetary graphics, rendering some prior art budgeting software unusable in such environments. Other problems with graphical representation of personal budgetary data will be known to persons of ordinary skill in the field.
Overall, the prior art struggled with how to show the relativeness of budget data in a manner that is intuitive, easy to understand, and may be depicted on a small display device, or a small portion of a larger display device.